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Abstract 

When implementing a propagator for a constraint, one must decide about vari- 
ants: When implementing min, should one also implement max? Should one im- 
plement linear constraints both with unit and non-unit coefficients? Constraint 
variants are ubiquitous: implementing them requires considerable (if not pro- 
hibitive) effort and decreases maintainability, but will deliver better performance 
than resorting to constraint decomposition. 

This paper shows how to use views to derive perfect propagator variants. A 
model for views and derived propagators is introduced. Derived propagators are 
proved to be indeed perfect in that they inherit essential properties such as correct- 
ness and domain and bounds consistency. Techniques for systematically deriving 
propagators such as transformation, generalization, specialization, and type con- 
version are developed. The paper introduces an implementation architecture for 
views that is independent of the underlying constraint programming system. A de- 
tailed evaluation of views implemented in Gecode shows that derived propagators 
are efficient and that views often incur no overhead. Without views, Gecode would 
either require 180000 rather than 40000 lines of propagator code, or would lack 
many efficient propagator variants. Compared to 8000 lines of code for views, the 
reduction in code for propagators yields a 1750% return on investment. 

1 Introduction 

When implementing a propagator for a constraint, one typically must also decide 
whether to implement some of its variants. When implementing a propagator for 
the constraint maxjxi , . . . ,x„} =y, should one also implement min{xi , . . . ,x„} =yl 
The latter can be implemented using the former as max{— jci, . . . , — jc„} = —y. When 
implementing a propagator for the linear equation Y!i=\ '^i^i — k for integer variables 
X, and integers a,- and k, should one also implement the special case L"=i-*^i — k for 
better performance? When implementing a propagator for the reified linear equation 
{Y!i=iXi = c) b, should one also implement (LLi-"^' c) ^ bl These two con- 
straints only differ by the sign of b, as the latter is equivalent to (L/'=i -"^i = c) <-> -^b. 

The two straightforward approaches for implementing constraint variants are to 
either implement dedicated propagators for the variants, or to decompose. In the last 
example, for instance, the reified constraint could be decomposed into two propagators, 
one for (LJLi x,- — c) ^ b' , and one for b ^ -^b', introducing an additional variable b\ 

Implementing the variants inflates code and documentation and is error prone. 
Given the potential code explosion, one may be able to only implement some vari- 
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ants (say, min and max). Other variants important for performance (say, ternary min 
and max) may be infeasible due to excessive programming and maintenance effort. De- 
composing, on the other hand, massively increases memory consumption and runtime. 

This paper introduces a third approach: deriving propagators from akeady existing 
propagators using views. This approach combines the efficiency of dedicated propaga- 
tor implementations with the simplicity and effortlessness of decomposition. 

Example 1 (Deriving a minimum propagator) Consider a propagator for the con- 
straint max{x,y) = z- Given three additional propagators for x' — —x, y' — —y, and 
z' — —z, we could propagate the constraint min(x',y) = z' using the propagator for 
max{x,y) = z. Instead, this paper proposes to derive a propagator using views that 
perform the simple transformations corresponding to the three additional propagators. 

Views transform input and output of a propagator. For example, a minus view on 
a variable x transforms the variable domain of x by negating each element, passes the 
transformed domain to the propagator, and performs the inverse transformation on the 
domain returned by the propagator With views, the implementation of the maximum 
propagator can be reused: a propagator for the minimum constraint can be derived from 
a propagator for the maximum constraint and a minus view for each variable. * 

This paper contributes an implementation-independent model for views and derived 
propagators, techniques for deriving propagators, concrete implementation techniques, 
and an evaluation that shows that views are widely applicable, drastically reduce pro- 
gramming effort, and yield an efficient implementation. 

More specifically, we identify the properties of views that are essential for deriv- 
ing perfect propagators. The paper establishes a formal model that defines a view as a 
function and a derived propagator as functional composition of views (mapping values 
to values) with a propagator (mapping domains to domains). This model yields all the 
desired results: derived propagators are indeed propagators; they faithfully implement 
the intended constraints; domain consistency carries over to derived propagators; dif- 
ferent forms of bounds consistency over integer variables carry over provided that the 
views satisfy additional yet natural properties. 

We introduce techniques for deriving propagators that use views for transformation, 
generalization, specialization, and type conversion of propagators. We show how to 
apply these techniques for different variable domains using various views and how 
views can be used for the derivation of dual scheduling propagators. 

We present and evaluate different implementation approaches for views and derived 
propagators. An implementation using parametric polymorphism (such as templates in 
C++) is shown to incur no or very low overhead. The architecture is orthogonal to the 
used constraint programming system and has been fully implemented in Gecode [10]. 
We analyze how successful the use of derived propagators has been for Gecode. 

Plan of the paper. Section 2 introduces constraints and propagators. Section 3 es- 
tablishes views and propagator derivation. Section 4 presents propagator derivation 
techniques. Section 5 describes an implementation architecture based on parametric 
propagators and range iterators. Section 6 discusses limitations of views. The imple- 
mentation is evaluated in Section 7, and Section 8 concludes. 

2 Preliminaries 

This section introduces constraints, propagators, and propagation strength. 
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Variables, constraints, and domains. Constraint satisfaction problems use a finite 
set of variables X and a finite set of values V. We typically write variables as x,y,z € X 
and values as v, w G V. 

A solution of a constraint satisfaction problem assigns a single value to each vari- 
able. A constraint restricts which assignments of values to variables are allowed. 

Definition 1 (Assignments and constraints) An assignment a is a function mapping 
variables to values. The set of all assignments is Asn = X — > V . A constraint c is a set 
of assignments, c G Con = ^(Asn) = ^{X — > V) (we write ^{S) for the power set 
of S). Any assignment a G c is a solution of c. * 

Constraints are defined on assignments as total functions on all variables. For a 
typical constraint c, only a subset vars(c) of the variables is significant; the constraint is 
the full relation for all x ^ vars(c). Constraints are either written as sets of assignments 
(for example, {a e Asn \a{x) < a{y)}) or as expressions with the usual meaning, using 
the notation [-J (for example, fx < y}). 

Example 2 (Sum constraint) Let X = {x,y,z} and V = {1,2,3,4}. The constraint 

[x = y + z] corresponds to the following set of assignments: 

Ix = y + zl = {{x 1-^ a,y 1-^ bjZi-^ c) \ a,b,c Aa = b + c} 
= {{x 1-^ 2,y 1-^ l,zi-^ l),{x>-^ 3,yi-^ l,z>-^2), 

(x I— *■ 3,)' H- s- 2,z 1-^ 1), (x 1-^ 4,)? I— *• 2,z I— *• 2)} * 

Definition 2 (Domains) A domain c/ is a function mapping variables to sets of values, 
such that d{x) C V. The set of all domains is Dom = X ^ ^{V). The set of values 
in d for a particular variable x, d{x), is called the variable domain of x. A domain d 
represents a set of assignments, a constraint, defined as 

con(<i) = {a G Asn | Vx G X : a{x) G d{x)} 

An assignment a G con(<i) is licensed by d. * 

Domains thus represent Cartesian sets of assignments. In this sense, any domain is 
also a constraint. For a more uniform representation, we take the liberty to use domains 
as constraints. In particular, a & d (instead of a G con(<i)) denotes an assignment a 
licensed by d, and cf^d denotes c n con(d). 

A domain d that maps some variable to the empty value set is failed, written J = 0, 
as it represents no valid assignments (con{d) = 0). A domain d representing a single 
assignment, con{d) = {a}, is assigned, and is written as d = {a}. 

Definition 3 (Constraint satisfaction problems) A constraint satisfaction problem 
(CSP) is a pair {d,C) of a domain d and a set of constraints C. The solutions of a 
CSP {d,C) are the assignments Hcensed by d that satisfy all constraints in C, defined 
as sol{{d,C)) = {a€ con(d) | Vc G C : a G c}. * 

Propagators. A propagation-based constraint solver employs propagators to imple- 
ment constraints. A propagator for a constraint c takes a domain d as input and removes 
values from the variable domains in d that are in conflict with c. 

A domain d is stronger than a domain d', written d C d', if and only if d{x) C d'{x) 
for all X G X. A domain d is strictly stronger than a domain d', written d C d', if and 
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only if d is stronger than d' and d{x) C d'(x) for some variable jc. The goal of constraint 
propagation is to prune values from variable domains, thus inferring stronger domains, 
without removing solutions of the constraints. 

A propagator is a function p that takes a domain as its argument and returns a 
stronger domain, it may only prune assignments. If the original domain is an assigned 
domain {a}, the propagator either accepts {p{{a]) = {a}) or rejects (p{{a}) — 0) it, re- 
alizing a decision procedure for its constraint. The pruning and the decision procedure 
must be consistent: if the decision procedure accepts an assignment, the pruning pro- 
cedure must never remove this assignment from any domain. This property is enforced 
by requiring propagators to be monotonic. 

Definition 4 (Propagators) A propagator is a function p e Dom ~> Dom that is 

■ contracting: p{d) C d for any domain d; 

■ monotonic: p{d') C p(d) for any domains d' C d. 

The set of all propagators is Prop. If a propagator p returns a strictly stronger domain 
{p{d) C d), we say that p prunes the domain d. The propagator p induces the unique 
constraint Cp defined by the set of assignments accepted by p: 

Cp^{ae Asn | p{{a}) = {a}} * 

Propagators can also be idempotent (p{p{d)) ~ p{d) for any domain d). Idempo- 
tency is not required to make propagation sound or complete, but it can make prop- 
agation more efficient [33]. Like idempotency, monotonicity as defined here is not 
necessary for soundness or completeness of a solver [34]. Most definitions and theo- 
rems in this paper are independent of whether propagators are monotonic or not. Non- 
monotonicity will thus only be discussed where it is relevant. 

Propagation strengtli. Each propagator induces a single constraint, but different 
propagators can induce the same constraint, differing in strength. Typical examples 
are propagators for the all-different constraint that perform naive pruning when vari- 
ables are assigned, or establish bounds consistency [26] or domain consistency [30]. 

In the literature, propagation strength is usually defined as a property of a domain 
in relation to a constraint. For example, a domain d is domain-consistent (also known 
as generalized arc-consistent) with respect to a constraint c if d{x) only contains values 
that appear in at least one solution of c for each variable x. As this paper is concerned 
with propagators, propagation strength is defined with respect to a propagator 

A propagator p is domain-complete if any domain it returns is domain-consistent 
with respect to Cp. For any constraint c, there is exactly one domain-complete prop- 
agator for c (as domains form a lattice). It is defined as pc{d) — dom(cp Od), where 
dom(c) is the domain relaxation of c, the strongest domain that contains all assign- 
ments of c, dom(c) = min {d \ c C d}. 

For constraints over integer variables {V C Z), several weaker notions of propaga- 
tion strength are known. The most well-known is bounds consistency, which in fact 
can mean one of four special cases: range, bounds(Z)), bounds(Z), and bounds(R) 
consistency (as discussed in [7, 28]). 

The first three differ in whether holes are ignored in the original domain, in the 
resulting domain, or in both, in that order. Holes in a domain are ignored by the func- 
tion hull((i) (x) = [min(ii(x)) .. max(ii(x))], which returns the convex hull of a variable 
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domain d{x) in Z. Bounds (R) consistency only requires solutions to be found in the 
real-valued relaxation of the constraint (written cjj), and is defined using the real-valued 
convex hull and domain relaxation (written hulls and domg). The different notions of 
bounds consistency give rise to the respective definitions of bounds completeness. 

Deiuiition 5 (Bounds completeness) A propagator p is 

■ range-complete if and only if p{d) C dom(cp nhull(<i)), 

■ bounds(D)-complete if and only if p{d) C hull(dom(cp n<i)), 

■ bounds(Z)-complete if and only if p{d) C huU(dom(cp nhuU(<i))), and 

■ bounds(IR)-complete if and only if p{d) C hull]R(dom]R(cpH nhuUR(<i))) 

for any domain d. * 

3 Views 

This section defines views and proves properties of view-derived propagators. 
3.1 Views and Derived Propagators 

Given a propagator p, a view is represented by two functions, (p and (p^, that can be 
composed with p such that (j? o p o 9 is the desired derived propagator. The func- 
tion (p transforms the input domain, and (p~ apphes the inverse transformation to the 

propagator's output domain. 

Definition 6 (Variable views and views) A variable view (pxGV —^V' for a variable 
X is an injective function mapping values to values. The set V' may be different from 
V, and the corresponding sets of assignments, domains, constraints, and propagators 
are called Asn', Dom', Con', and Prop', respectively. 

Given a family of variable views (Px for ail x gX, we hft them point-wise to as- 
signments: (p/^sr\{a){x) ~ (px{a{x)). A view <p <E Con Con' is a family of variable 
views, lifted to constraints: (p{c) = {9Asn(«) | a € c}. The inverse of a view is defined 
as (j[)~(c) = {a e Asn I (j[)Asn(«) G c}. * 

Definition 7 (Derived propagators and constraints) Given a propagator p G Prop' 

and a view <p, the derived propagator <p{p) € Prop is defined as <p{p) = <p^ o pocp. 
Similarly, a derived constraint is defined to be <p^{c) G Con for a given c G Con'. 

Examples (Scale views) Given a propagator p for the constraint c = \x = y\, we 
want to derive a propagator for c' =\x = 2y\ using a view (p such that (p~ (c) = c' . 

Intuitively, the function (p leaves x as it is and scales y by 2, while (p^ does the 
inverse transformation. We thus define <px{v) = v and <py{v) = 2v. That clarifies the 
need for different sets V and V', as V' must contain all elements of V multipUed by 2. 

The derived propagator is ^{p) = (p^ o p o (p. We say that (p{p) "uses a scale view 
on"y, meaning that (py is the function defined as <j!>y(v) = 2v. Similarly, using an identity 
view on x amounts to (px being the identity function on V. 

Given the assignment a = (x 2,y 1), we first apply (p and get (p{{a}) = {{x^ 
2,y I— > 2)}. This is accepted by p and returned unchanged, so 9^ transforms it back 
to {a}. Another assignment a' = (x 1— > l,y 1— > 2) is transformed to <p({a'}) = {{x 
l,y ^ 4)}, rejected (p{(p{{a'})) = 0), and the empty domain is mapped to the empty 
domain by (p^. The propagator (p{p) induces (p^ (c). * 
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3.2 Correctness of Derived Propagators 

Derived propagators are well-defined and correct: a derived propagator ^{p) is in fact 
a propagator, and it induces the desired constraint (c^^^j — (p^{cp)). The proofs of 
these statements employ the following direct consequences of the definitions of views: 

PI. (p and (p^ are monotonic by construction (as (p and (p^ are defined point-wise). 

P2. (p^ o (p = id (the identity function, as (p is injective). 

P3. |9({fl})| = 1, ^(0) =0. 

P4. For any view (p and domain d € Dom, we have (p{d) £ Dom', and for any d' G 
Dom', we have <p^{d') E Dom (as views are defined point-wise). 

Proposition 1 (Correctness) For a propagator/? and view (p, <p{p) is a propagator. * 

Proof. The derived propagator is well-defined because both <p{d) and (p^{d) are do- 
mains (see P4 above). We have to show that (p^ o p o (p is contracting and monotonic. 

For contraction, we have p{(p{d)) C (p{d) as p is contracting. From monotonicity 
of (p^ (with PI), it follows that (p^ {p{(p{d))) C (p-{(p{d)). As (p' o(p = id (with P2), 
we have (p^{p{(p{d))) C d, which proves that (p{p) is contracting. 

Monotonicity is shown as follows for all domains d',d with d' C d: 

(p{d') C (p{d) ((p monotonic, PI) 

=^ p{(p{d')) C p{(p{d)) (/? monotonic) 

(p^{p{(p{d'))) C(p^{p{(p{d))) ((p" monotonic, PI) 

In summary, for any propagator p, <p{p) = (p^ o p o (p is a propagator. ■ 

Non-monotonic propagators as defined in [34] must at least be weakly monotonic, 
which means that p{{a}) ^ p{d) for all domains d and assignments a Ed. The above 
proof can be easily adjusted to weakly monotonic propagators by replacing d' with {a} 
and using P3 in the second line of the proof. 

Proposition 2 (Induced constraints) Let p be a propagator, and let (p be a view. 
Then ^{p) induces the constraint <p^(cp). * 

Proof. As p induces Cp, we know p{{a}) — Cp n {a} for all assignments a. With 
= 1 (P3)> we have p{<p{{a})) — Cpf\<p{{a}). Furthermore, we know that 
Cp n ^({fl}) is either or ^({a}). 

■ Case 0.- We have (p^ {p{(p{{a}))) = = {«' G Asn | a = a' A^Asn(fl) £ Cp] = 
(p-{cp)r\{a]. 

■ Case ^{{a}): With P2, we have 9" o 9 = id and hence {p{^{{a}))) — {a}. 
Furthermore, (j?^(cp) n {a} — {«' G Asn \ a = a' A (pAsn{a) G Cp} = {a}. 

Together, this shows that (p^ o po (p{{a}) — {a} f) (p^{cp). ■ 

Another important property is that views preserve contraction: if a propagator p 
prunes a domain, the pruning will not be lost after transformation by (p^. 

Proposition 3 (Views preserve contraction) Let phe a propagator, let ^ be a view, 
and let li be a domain such that p{<p{d)) C <p{d). Then (p{p){d) C d. * 
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Proof. The definition of (p^{c) is {a G Asn | (p/\sn(a) G c}. Hence, |(p^(c)| < \c\. Sim- 
ilarly, we know that \(p{c) \ = \c\. From p{(p{d)) C (p{d), it follows that \p{(p{d))\ < 
\(p{d)\. Together, this yields \(p(p){d)\ < \(p{d)\ = \d\. We have seen in Proposition 1 
that (p{p){d) C d, so we can conclude that (p{p){d) C d. ■ 

3.3 Completeness of Derived Propagators 

Ideally, a propagator derived from a domain- or bounds-complete propagator should 
inherit its completeness. It turns out to not generally be true for all notions of complete- 
ness and all views. This section first shows how bounds (Z) completeness is inherited, 
and then generalizes this result to the other notions. 

The key insight is that bounds(Z) completeness of propagators derived using a view 
(p depends on whether (p and (p^ commute with the hull operator, as defined below. 

Definition 8 A constraint c is a (p-constraint for a view (p if and only if for all a e c, 
there is a b G Asn such that a = (p/\sn{b). A view (p is hull-injective if and only if 
(p^(hull(dom(c))) = hull(dom((p^(c))) for all ^-constraints c. It is hull-surjective if 
and only if <p{\m\\{d)) — hull(^(t/)) for all domains d. It is hull-bijective if and only if 
it is hull-injective and hull-surjective. * 

The proofs rely on the additional fact that views commute with set intersection. 

Lemma 1 For any view ^, the equation ^^(ci nc2) = 9^ (ci) n 9^ (c2) holds. * 

Proof. By definition of we have 



As ^Asn is a function, this is equal to 

{a e Asn I (pAsn(fl) G ci}n{fl e Asn I ^Asn(fl) e C2} = (p"(ci)n(p"(c2) ■ 

Theorem 1 (Bounds(Z) completeness) Let p be a bounds(Z)-complete propagator. 
For any hull-bijective view <p, the propagator ^{p) is bounds(Z)-complete. * 

Proof. From Proposition 2, we know that ^{p) induces the constraint <p^{cp). By 
monotonicity of <p^ (with PI) and bounds(Z) completeness of p, we know that 



We now use the fact that both <p and <p commute with hull(-) and set intersection: 
9" (hull(dom(cp n \m\\{((){d)) ) ) ) 



The second step uses hull injectivity, so it requires Cp D ^(hull((i)) to be a ^-constraint. 
All assignments in a ^-constraint have to be the image of some assignment under 



<P (Cl nC2) = {fl e Asn I ^Asn(fl) e Cl A9Asn(a) e C2} 



(p o po(p{d) (- (p (hull (dom (cp n hull 



(p" (hull(dom(cp n (p{hu\l{d))))) 
hull(dom(^"(cp n (p{hu\l{d))))) 
hull(dom(^" (cp) n (p' {(p{hu\l{d))))) 
hull(dom(^"(cp) nhull(£/))) 



(hull-surjective) 
(hull-injective) 
(commute with n) 
(P2) 
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^Asn- This is the case here, as the intersection with (p{hiill{d)) can only contain such 
assignments. So in summary, we get 

(p^ opo (p{d) C hull(dom((p^ (cp) nhull(t/)) 
which is the definition of (p{p) being bounds(Z)-complete. ■ 

Stronger notions of completeness. Similar theorems hold for domain completeness, 
range and bounds(Z) completeness. The theorems directly follow from the fact that 
any view (p is domain-injective, meaning that ^^(dom(c)) = dom((j!)^(c)) for all con- 
straints c. We split this statement into the following two lemmas. 

Lemma 2 Given a constraint c, let d = dom(c). Then for all x G X, we have v G 

d{x) <^3a G c : a{x) — v. » 

Proof. We prove both directions of the equivalence: 

^ There must be such an assignment a because otherwise one can construct a 
strictly stronger d' C d with v ^ d'{x) such that still c C d'. 

Each domain d' in the intersection f] {d' G Dom | c C con(ii')} must contain 
the value v G d'{x) as c C d' . So for the result of the intersection rf, v G d{x)M 

Lemma 3 Any view <p is domain-injective. * 

Proof. We have to show that 9^(dom(c)) =dom(^^(c)) holds for any constraint c and 
any view <p. For clarity, we write the equation including the implicit con(-) operations: 
(fi^(con(dom(c))) — con(dom((p^(c))). By definition of and con(-), we have 

(j[)^(con(dom(c))) = {a G Asn | Vx G X : <pf^sn{a){x) G dom(c)(x)} 

= {fl G Asn I Vx G X 3^7 G c : (pAsn («) {x) =b{x)] (Lemma 2) 

As ^Asn is an injective function, we can find such a b that is in the range of ^Asn, if and 
only if there is also a /?' G <p^{c) such that (pAsr\{b') — b. Therefore, we get 

[a G Asn I Vx gX 3/7' G 9"(c) : a{x) ^b\x)] 
= {a G Asn I Vx G X : a{x) G dom(^^(c))(x)} 
= con(dom((p^(c))) ■ 

The following three theorems express under which conditions the different notions 
of completeness are preserved when deriving propagators. The proofs for these theo- 
rems are analogous to the proof of Theorem 1, using Lemma 3. 

Theorem 2 (Bounds(i)) completeness) Let p be a bounds(D)-complete propagator. 
For any hull-injective view <p, the propagator ^{p) is bounds(D)-complete. * 

Theorem 3 (Range completeness) Let be a range-complete propagator. For any 
hull-surjective view <p, the propagator <p{p) is range-complete. * 

Theorem 4 (Domain completeness) Let be a domain-complete propagator, and let 
(p be a view. Then <p{p) is domain-complete. * 
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A propagator derived from a bounds(Z)-complete propagator and a hull-injective 
but not hull-surjective view is only bounds(M)-complete. This is exactly what we 
would expect from a propagator for linear equations, as the next example demonstrates. 

Example 4 (Linear constraints) A propagator for a linear constraint ~ J^"^ j Xi — 
c| and n scale views (see Example 3) yield a propagator for a linear constraint with 
coefficients C£„ = [LLi '^'^i — ^\ 

The usual propagator for a linear constraint with coefficients achieves bounds(M) 
consistency in linear time 0(n) [15]. However, it is bounds(Z)-complete for unit co- 
efficients. Hence, the above-mentioned property applies: The propagator for is 
bounds (Z) -complete, scale views are only hull-injective, so the derived propagator for 

is bounds(K)-complete. Implementing the simpler propagator without coefficients 
and deriving the variant with coefficients yields propagators with exactly the same run- 
time complexity and propagation strength as manually implemented propagators. * 

3.4 Additional Properties of Derived Propagators 

This section discusses how views can be composed, and how derived propagators be- 
have with respect to idempotency and subsumption. 

View composition. A derived propagator permits further derivation. Consider a 
propagator p and two views Then (p'{(p{p)) is a perfectly acceptable derived 

propagator, and properties like correctness and completeness carry over transitively. 
For instance, we can derive a propagator for Jx — y = c| from a propagator for |x + y = 
0], combining an Oj^sef v/ew ((py(v) = v + c) and a minus view ((Py{v) = — v) ony. This 
yields a propagator for [x + ( — (3' + c ) ) = 0]] = — y = cj . 

Fixed points. Schulte and Stuckey [33] show how to optimize the scheduling of prop- 
agators that are known to be at a fixed point. Views preserve fixed points of propaga- 
tors, so the same optimizations apply to derived propagators. 

Proposition 4 Let p be a propagator, let 9 be a view, and let li be a domain. If (p{d) 
is a fixed point of p, then li is a fixed point of (p{p). * 

Proof. Assume p{p{(p{d))) = p{(p{d)). We have to show (p{p){d) = (p{p){(p{p){d)). 
With the assumption, we can write (p{p){d) = {(p^ op 0/70 <p){d). We know that 
<po(p^[c) = c if |^^(c)| = |c|. As we first apply (jO, this is the case here, so we can add 
^o^^ in the middle, yielding {(p^ opo((po(p^)opo(p)[d). With function composition 
being associative, this is equal to (p{p){(p(p)(d)). m 

Subsumption. A propagator is subsumed (also known as entailed) by a domain d if 
and only if for all stronger domains d' C d, p{d') ~ d' . Subsumed propagators cannot 
do any pruning in the remaining subtree of the search, and can therefore be removed. 
Deciding subsumption is coNP-complete in general, but for many practically relevant 
propagators an approximation can be decided easily (such as when a domain becomes 
assigned). The following theorem states that the approximation is also valid for the 
derived propagator 

Propositions Let p be a propagator and let (p be a view. The propagator <p{p) is 
subsumed by a domain d if and only if p is subsumed by ^{d). * 
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Proof. With P2 we get that yd' Cd : (p^ {p{(p{d'))) = d' is equivalent to ^d' <Zd : 
(p^ {p{(p{d'))) = <p^{<p{d')). As <p^ is a function, and because it preserves contrac- 
tion (see Proposition 3), this is equivalent to Vc/' C d : p{(p{d')) — <p{d'). This can be 
rewritten to Vt/" C ^){d) : p{d") = d" because all (p{d') are subsets of (p{d). m 

3.5 Related Work 

While the idea to systematically derive propagators using views is novel, there are a 
few related approaches we can point out. Reusing functionality (like a propagator) by 
wrapping it in an adaptor (like a view) is of course a much more general technique — 
think of higher-order functions like fold or map in functional programming languages; 
or chaining command-line tools in Unix operating systems using pipes. 

Propagator derivation. Views that perform arithmetic transformations are related to 
the concept of indexicals (see [5, 36]). An indexical is a propagator that prunes a sin- 
gle variable and is defined in terms of range expressions. In contrast to views, range 
expressions can involve multiple variables, but on the other hand only operate in one di- 
rection. For instance, in an indexical for the constraint Jx = y + z| , the range expression 
y + z would be used to prune the domain of x, but not for pruning the domains of y or z- 
Views must work in both directions, which is why they are limited in expressiveness. 

Unit propagation in SAT solvers performs propagation for Boolean clauses, which 
are disjunctions of literals, which in turn are positive or negated Boolean variables. 
In implementations such as MiniSat [9], the Boolean clause propagator is in fact de- 
rived from a simple n-ary disjunction propagator and literal views of the variables that 
perform negation for the negative literals. 

Constraint composition. Instead of regarding a view (p as transforming a constraint 
c, one can regard (p as additional constraints, implementing the decomposition. As- 
suming vars(c) — xi, . . . ,x„, we use additional variables Xj , . . . ,x',. Instead of c, we 
use c' = c[xi/x\ ,x„/x'„], which is the same relation as c, but on Xj , . . . ,x'„. Finally, 
n view constraints c,p i link the original variables to the new variables, each c,pj be- 
ing equivalent to the relation xj = ^, (x, ). The solutions of the decomposition model, 
restricted to the x\,. . . ,x„, are exactly the solutions of the original view-based model. 

Every view constraint C(pj shares exactly one variable with c and no variable with 
any other c,p ,. Thus, the constraint graph is Berge-acyclic [3], and a fixed point can 
be computed by first propagating all the C(p.,, then propagating c[xi/xj , . . . ,x„/x'n], 
and then again propagating the c^j. This is exactly what (p^ o po(p does. Constraint 
solvers typically do not provide any means of specifying the propagator scheduling in 
such a fine-grained way (Lagerkvist and Schulte show how to use propagator groups 
to achieve this [20]). Thus, deriving propagators using views is also a technique for 
specifying perfect propagator scheduling. 

On a more historical level, a derived propagator is related to the notion of path 
consistency. A domain is path-consistent for a set of constraints, if for any subset 
{x,y,z} of its variables, v'l E d{x) and V2 S d{y) implies that there is a value V3 G d{z) 
such that the pair (vi,V2) satisfies all the (binary) constraints between x and y, the 
pair (vi, V3) satisfies all the (binary) constraints between x and z, and the pair (V3, V2) 
satisfies all the (binary) constraints between z and y [21]. If ^{p) is domain-complete 
for <p^{c), then it achieves path consistency for the constraint c[xi/xj , . . . ,x„/x',] and 
all the C(f,^i in the decomposition model. 
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4 Propagator Derivation Techniques 

This section introduces techniques for deriving propagators using views. The tech- 
niques capture the transformation, generahzation, specialization, and type conversion 
of propagators and are shown to be widely applicable across variable domains and 
apphcation areas. 

4.1 Transformation 

Boolean connectives. For Boolean variables, where Y — {0, 1}, the only view apart 
from identity for Boolean variables captures negation. A negation view on x defines 
(Px{v) = 1 — V foix e X and v G V. As already noted in Section 3.5, deriving propagators 
using Boolean views thus means to propagate using literals rather than variables. 

The obvious application of negation views is to derive propagators for all Boolean 
connectives from just three propagators. A negation view forx inx —y yields a propa- 
gator for -IX = y. From disjunction x Vy = z one can derive conjunction x Ay ^ z with 
negation views on x, y, z, and implication x ^ y — z with a negation view on x. From 
equivalence x ^y = z one can derive exclusive or x ©y = z with a negation view on z- 

As Boolean constraints are widespread, it pays off to optimize frequently occur- 
ring cases of propagators for Boolean connectives. One important propagator is for 
— y with arbitrarily many variables. Again, conjunction can be derived with 
negation views on the x, and on y. Another important propagator implements the 
constraint V"=i-'^f = 1- A dedicated propagator for this constraint is essential as the 
constraint occurs frequently and can be implemented efficiently using watched literals, 
see for example [12]. With views all implementation work is readily reused for con- 
junction. This shows a general advantage of views: effort put into optimizing a single 
propagator directly pays off for all other propagators derived from it. 

Boolean cardinality. Like the constraint VLi-^' = 1' '^he Boolean cardinality con- 
straint Y-'Ui^i > c occurs frequently and can be implemented efficiently using watched 
literals (requiring c + 1 watched literals. Boolean disjunction corresponds to the case 
where c—l). But also a propagator for LJLi x, < c can be derived using negation views 
on the X, with the following transformation: 



Reiflcation. Many reified constraints (such as (L"=i-'fi = c) b) also exist in a 
negated version (such as (L"=i'<^; c) ^ b). Deriving the negated version is trivial 
by using a negation view on the Boolean control variable b. This contrasts nicely with 
the effort without views: either the entire code must be duplicated or the parts that 
perform checking whether the constraint or its negation is subsumed must be factored 
out and combined differently for the two variants. 

Transformation using set views. Set constraints deal with variables whose values 
are finite sets. Using complement views (analogous to Boolean negation, as sets with 
their usual operations also form a Boolean algebra) on x,y,z with a propagator for 
xOy = z yields a propagator for xUy = z- A complement view on y yields x\y = z- 
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est(f') ect(f') Ist(f') lct(;') est(f) ect(r) Ist(f) lct(f) 



Figure 1 : Task f and its dual task t' using a minus view 

Transformation using integer views. The obvious integer equivalent to negation 
views for Boolean variables are minus views: a minus view on an integer variable 
X is defined as <Px{v) = —v. Minus views help to derive propagators following simple 
transformations: for example, min(x,3') = z can be derived from max(jic,3') = z by using 
minus views for x, y, and z- 

Transformations through minus views can improve performance in subtle ways. 
Consider a bounds(Z)-complete propagator for multiplication xxy ~ z (for example, 
[1, Section 6.5] or [32]). Propagation depends on whether zero is still included in the 
domains of x, y, or z- Testing for inclusion of zero each time the propagator is exe- 
cuted is inefficient and leads to a convoluted implementation. Instead, one would like 
to rewrite the propagator to special variants where x, y, and z are either strictly posi- 
tive or negative. These variants can propagate more efficiently, in particular because 
propagation can easily be made idempotent. Instead of implementing three different 
propagators {x^y^z strictly positive; only xory strictly positive; only z strictly positive), 
a single propagator assuming that all views are strictly positive is sufficient. The other 
propagators can be derived using minus views. 

Again, with views it becomes realistic to optimize a single implementation of a 
propagator and derive other, equally optimized, implementations. The effort to imple- 
ment all required specialized versions without views is typically unrealistic. 

Sclieduling propagators. An important application area is constraint-based schedul- 
ing, see for example [2]. Many propagation algorithms for constraint-based scheduling 
are based on tasks, where a task t is characterized by its start time, processing time 
(how long does the task take to be executed on a resource), and end time. Scheduling 
algorithms are typically expressed in terms of earliest start time (est(f)), latest start 
time (lst(f )), earliest completion time (ect(f )), and latest completion time (lct(r)). 

Another particular aspect of scheduUng algorithms is that they are often required 
in two, mutually dual, variants. Let us consider not-first/not-last propagation as an 
example. Assume a set of tasks T and a task f ^ T to be scheduled on the same resource. 
Then t cannot be scheduled before the tasks in T (f is not-first in T U {?}), if ect(f ) > 
Ist(r) (where Ist(r) is a conservative estimate of the latest start time of all tasks in T). 
Hence, est(f ) can be adjusted to leave some room for at least one task from T . The 
dual variant is that t is not-last: if ect(r) > Ist(f) (again, ect(r) estimates the earliest 
completion time of T), then lct(f ) can be adjusted. 

Running the dual variant of a scheduling algorithm on tasks f G T is the same as 
running the original algorithm on the dual tasks t' £ T\ which are simply mirrored at 
the 0-origin of the time scale (see Figure 1): 

est(f') = -lct(r) ect(f') -lst(f) Ist(f') = -ect(f) lct(f') = -est(f) 

The dual variant of a scheduling propagator can be automatically derived using a minus 
view that transforms the time values. In our example, only a propagator for not-first 
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needs to be implemented and the propagator for not-last can be derived (or vice versa). 
This is in particular beneficial if the algorithms use sophisticated data structures such 
as £2-trees [37]. Here, also the data structure needs to be implemented only once and 
the dual data structure for the dual propagator is derived. 

4.2 Generalization 

Common views for integer variables capture linear transformations of the integer val- 
ues: an ojfset view for o G Z on x is defined as <Px{v) ~v-\-o, and a scale view for a G Z 
on X is defined as <Px{v) = av. 

Offset and scale views are useful for generalizing propagators. Generalization has 
two key advantages: simplicity and efficiency. A more specialized propagator is often 
simpler to implement (and simpler to implement correctly) than a generalized version. 
The specialized version can save memory and runtime during execution. 

We can devise an efficient propagation algorithm for a linear equality constraint 
£"^[jt:, = c for the common case that the linear equation has only unit coefficients. 
The more general case = c can be derived by using scale views for a, on 

Xi (the same technique of course applies to linear inequalities and disequality rather 
than equality). Similarly, a propagator for all-different{xi ,x„) can be generalized 
to all-different{ci +xi,...,c„ +x„) by using offset views for c,- G Z on x,-. Likewise, 
from a propagator for the element constraint a[x] —y for integers a i , . . . , a„ and integer 
variables x and y, we can derive the generalized version a [x + o] = y with an offset view, 
where o G Z provides a useful offset for the index variable x. 

These generalizations can be applied to domain- as well as bounds-complete prop- 
agators. While most Boolean propagators are domain-complete, bounds completeness 
plays an important role for integer propagators. Section 3.3 shows that, given appro- 
priate huU-surjective and/or hull-injective views, the different notions of bounds con- 
sistency are preserved when deriving propagators. 

The views for integer variables presented in this section have the following prop- 
erties: minus and offset views are huU-bijective, whereas a scale view for a G Z on x 
is always hull-injective and only huU-surjective if a = 1 or a = — 1 (in which cases it 
coincides with the identity view or a minus view, respectively). 

4.3 Specialization 

We employ constant views to speciaUze propagators. A constant view behaves like 
an assigned variable. In practice, specialization has two advantages. Fewer variables 
require less memory. And specialized propagators can be compiled to more efficient 
code, if the constants are known at compile time. 
Examples for specialization are 

■ a propagator for binary linear inequality x + y <c derived from a propagator for 
X + y + z < c by using a constant for z; 

■ a reified propagator for {x = c) ^ b from (x =y) ^ b and a constant c for y; 

■ propagators for the counting constraints | {/ 1 x, = c} | = z and | {; | x, = y} | — c 
from a propagator for | {/ 1 x,- = y} | = z; 

■ a propagator for set disjointness from a propagator for x Ply = z and a constant 
empty set for z; and many more. 
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We have to straightforwardly extend the model for constant views. Propagators may 
now be defined with respect to a superset of the variables, X' Z^X. A constant view for 
the value on a variable z^X'\X translates between the two sets of variables: 

(p{c) = {a[k/z] I a e c} ^"(c) = {a\x | a £ c} 

Here, a\k/z\ means augmenting the assignment a so that it maps z to k, and a^x is the 
functional restriction of a to the set X. 

It is important that this definition preserves failure. If a propagator returns a failed 
domain d that maps z to the empty set, then (p^ [d) is the empty set, too (recall that this 
is really ^^(con(c/)), and con{d) =%\i d{z)— 0). 

4.4 Type Conversion 

A type conversion view lets propagators for one type of variable work with a different 
type, by translating the underlying representation. Our model already accommodates 
for this, as a view <Px maps elements between different sets V and V' . 

Integer views. Boolean variables are essentially integer variables restricted to the 
values {0, 1}. Constraint programming systems may choose a more efficient imple- 
mentation for Boolean variables and hence the variable types for integer and Boolean 
variables differ. By wrapping an efficient Boolean variable in an integer view, all in- 
teger propagators can be directly reused with Boolean variables. This can save sub- 
stantial effort; for example, an implementation of the regM/ar-constraint for Boolean 
variables can be derived which is actually useful in practice [19]. 

Singleton set views. A singleton set view on an integer variable x, defined as <Px{v) — 
{v}, presents an integer variable as a set variable. Many constraints involve both integer 
and set variables, and some of them can be expressed with singleton set views. A 
simple constraint is x G y, where x is an integer variable and y a set variable. Singleton 
set views derive it as {x} C y. This extends to {x} oy for all other set relations o. 

Singleton set views can also be used to derive pure integer constraints from set 
propagators. For example, the constraint same{xi ,Xi,,yi ,yi„) with integer vari- 
ables Xi,yi states that the variables Xi take the same values as the variables y,. With sin- 
gleton set views, ULil-^f} = UyLiI-^;} implements this constraint (albeit with weaker 
propagation than the algorithm presented in [4]). 

Set bounds and complete set domain variables. Most systems approximate set 
variable domains as set intervals defined by lower and upper bounds [25, 13]. How- 
ever, [16] introduces a representation for the complete domains of set variables, using 
ROBDDs. Type conversion views can translate between set interval and ROBDD- 
based implementations. We can derive a propagator on ROBDD-based variables from 
a set interval propagator, and thus reuse set interval propagators for which no efficient 
ROBDD representation exists. 

4.5 Applicability and Return on Investment 

To get an overview of how applicable the presented techniques for propagator deriva- 
tion are, let us consider the use of views in Gecode (version 3.1.0). Table 1 shows the 
number of propagator implementations and the number of propagators derived from the 
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Table 1: Number of implemented vs. derived propagators 



Variable type 


Implemented 


Derived 


Ratio 


Integer 


11 


400 


5.19 


Boolean 


28 


91 


3.25 


Set 


28 


122 


4.36 


Overall 


133 


613 


4.61 



class IntVar { 
private: int _min, _max; 

public: int min (void) { return _min; } 
int max (void) { return _max; } 

void adjmin(int n) { if (n > _min) 
void adjmax(int n) { if (n < _max) 

}; 

class OffsetView { 
protected: IntVar* x; int o; 

public: Of fsetView (IntVar* xO, int oO) : x(xO), o(oO) {} 
int min (void) { return x->min()+o; } 
int max (void) { return x->max()+o; } 
void adjmin(int n) { x->ad jmin (n-o ) ; } 
void adjmax(int n) { x->ad jmax (n-o) ; } 

}; 

Figure 2: Integer variable and offset view 

implementations. On average, every propagator implementation results in 4.6 derived 
propagators. Propagator implementations in Gecode account for more than 40000 lines 
of code and documentation. As a rough estimate, deriving propagators using views thus 
saves around 140000 lines of code and documentation to be written, tested, and main- 
tained. On the other hand, the views mentioned in this section are implemented in less 
than 8000 lines of code, yielding a 1750% return on investment. 

5 Implementation 

This section presents an implementation architecture for views and derived propaga- 
tors, based on making propagators parametric. Deriving a propagator then means in- 
stantiating a parametric propagator with views. The presented architecture is an or- 
thogonal layer of abstraction on top of any solver implementation. 

5.1 Views 

The model introduced views as functions that transform the input and output of a prop- 
agator, which maps domains to domains. In an object-oriented implementation of this 
model, a propagator is no longer a function, but an object with a propagate method 
that accesses and modifies a domain through the methods of variable objects. Such an 
object-oriented model is used for example by ILOG Solver [27] and Choco [18], and 
is the basis of most of the current propagation-based constraint solvers. 

Figure 2 shows 0+ classes for a simple integer variable (just representing bounds 
information) and a corresponding offset view. The view has the same interface as the 
variable, so that it can be used in its place. It contains a pointer to the underlying integer 
variable and delegates all the operations, performing the necessary transformations. 



.min = n; } 
.max = n; } 
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template<class VX, class VY> 
class Eq : public Propagator { 
protected: VX* x; VY* y; 

public: Eq(VX* xO, VY* yO) : x(xO), y(yO) {} 

virtual void propagate (void) { 

x->adjmin (y->min ( ) ) ; x->ad jmax (y->max ( ) ) ; 
y->adjmin (x->min ( ) ) ; y->ad jmax (x->max ( ) ) ; 

} 

}; 

Figure 3: Parametric equality propagator 



5.2 Deriving Propagators 

In order to derive a propagator using view objects like the above, we use parametricity, 
a mechanism provided by the implementation language that supports the instantiation 
of the same code (the propagator) with different parameters (the views). 

Figure 3 shows a simple equality propagator The propagator is based on C++ tem- 
plates, it is parametric over the types of the two views it uses and can be instantiated 
with any view that provides the necessary operations. This type of parametricity is 
called parametric polymorphism, and is available in other programming languages for 
example in the form of Java generics [14] or Standard ML functors [22]. 

Given two pointers to integer variables x and y, the propagator can be instantiated 
to implement fx — y] as follows (using the intvar class from Figure 2): 

new Eq<IntVar , IntVar> (x, y ) ; 

The following instantiation yields a propagator for |x = y + 2] : 

new Eq<IntVar , Of f setView> (x, new Of f setView (y , 2 ) ) ; 

Events. Most constraint solvers schedule the execution of propagators according to 
events (see for example [31]). For example, a propagator p for |x < y] can only prune 
the domain (and thus should only be executed) if either the lower bound of x or the 
upper bound of y changes, written Ibc(x) and ubc(y). We say that p subscribes to the 
event set {lbc(ji:), ubc(y)}. 

Now assume that p' is derived from p using minus views on x and y, thus imple- 
menting X > y. Obviously, p' should subscribe to the dual event set, {ubc(ji:), Ibc(y)}. 
In the implementation, views provide all the operations needed for event handling (such 
as subscription) and perform the necessary transformations of event sets. 

5.3 Parametricity 

Independent of the concrete implementation, views form an orthogonal layer of ab- 
straction on top of any propagation-based constraint solver. As long as the implemen- 
tation language provides some kind of parametricity, and variable domains are accessed 
through some form of variable objects, propagators can be derived using views. 

In addition to parametric polymorphism, two other forms of parametricity exist, 
functional parametricity and dynamic binding. Functional parametricity means that 
in languages such as Standard ML [22] or Haskell [24], a higher-order function is 
parametric over its arguments. Dynamic binding is typically coupled with inheritance 
in object-oriented languages (virtual function calls in C++, method calls in Java). Even 
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in languages that lack direct support for parametricity, parametric behavior can often 
be achieved using other mechanisms, such as macros or function pointers in C. 

Choice of parametricity. In C++, parametric polymorphism and dynamic binding 
have advantages and disadvantages as it comes to deriving propagators. 

Templates are compiled by monomorphization: the code is replicated and special- 
ized for each instance. The compiler can generate optimized code for each instance, 
for example by inlining the transformations that a view implements. 

Achieving high efficiency in C++ with templates sacrifices some expressiveness. In- 
stantiation can only happen at compile-time. Hence, either C++ must be used for mod- 
eling, or all potentially required propagator variants must be instantiated explicitly. 
The choice which propagator to use can however be made at runtime: for linear equa- 
tions, for instance, if all coefficients are units, the optimized original propagator can be 
posted. 

For n-ary constraints, compile-time instantiation can be a limitation, as all arrays 
must be monomorphic (contain only a single kind of view). For example, one cannot 
mix scale and minus views in linear constraints. For some propagators, we can work 
around this restriction using more than a single array of views. For example, a propaga- 
tor for a linear constraint can employ two arrays of different view types, one of which 
may then be instantiated with identity views and the other with minus views. While 
this poses a limitation in principle, our experience from Gecode suggests that there are 
only few propagators in practice that suffer from this limitation. 

Dynamic binding is more flexible than parametric polymorphism, as instantiation 
happens at runtime and arrays can be polymorphic. This flexibility comes at the cost of 
reduced efficiency, as the transformations done by view operations typically cannot be 
inlined and optimized, but require additional virtual method calls. Section 7 evaluates 
empirically how these virtual method calls affect performance. 

CompUe-time versus runtime constants. Some views involve a parameter, such as 
the coefficient of a scale view or the constant of a constant view. These parameters 
can again be instantiated at compile-time or at runtime. For instance, one can regard 
a minus view as a compile-time specialization of a scale view with coefficient — 1, 
and a zero view may specialize a constant view. With the constants being known at 
compile-time, the compiler can apply more aggressive optimizations. 

5.4 Iterators 

Typical domain operations involve a single integer value, for instance adjusting the 
minimum or maximum of an integer variable. These operations are not efficient if a 
propagator performs full domain reasoning on integer variables or deals with set vari- 
ables. Therefore, set-valued operations, like updating a whole integer variable domain 
to a new set, or excluding a set of elements from a set variable domain, are important for 
efficiency. Many constraint programming systems provide an abstract set-datatype for 
accessing and updating variable domains, as for example in Choco [6], ECL'PS'^ [8], 
SlCStus Prolog [35], and Mozart [23]. ILOG Solver [17] only allows access by iterat- 
ing over the values of a variable domain. 

This section develops iterators as one particular abstract datatype for set- valued op- 
erations on variables and views. There are two main reasons to discuss iterators in this 
paper First, iterators provide simple, expressive, and efficient set-valued operations on 
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variables. Second, and more importantly, iterators transparently perform the transfor- 
mations needed for set-valued operations on views, and thus constitute a perfect fit for 
deriving propagators. 

Range sequences and range iterators. A range [m . . n] denotes the set of integers 
{/ £ Z I m < Z < n}. A range sequence ranges(5) for a finite set of integers 5 C Z 
is the shortest sequence i = ([mi ..«]],..., [m^. .. n^]) such that S — |jf=i [nii .. n,] and 
the ranges are ordered by their smallest elements (;«,■ < m,_|_i for 1 < / < k). We thus 
define the set covered by a range sequence as set(s) = |jf=i •■ The above range 
sequence is also written as ([m; .. Clearly, the range sequence of a set is unique, 

none of its ranges is empty, and n, + 1 < m,+i for \ <i <k. 

A range iterator for a range sequence s = ([«, .. is an object that provides 

iteration over s: each of the [m, . . n,] can be obtained in sequential order but only one at 
a time. A range iterator r provides the following operations: r.done() tests whether all 
ranges have been iterated, r.next () moves to the next range, and r.min() and r.max() 
return the minimum and maximum value for the current range. By set(r) we refer to 
the set defined by an iterator r (which must coincide with set(s)). 

A range iterator naturally hides its implementation. It can iterate a sequence (for 
instance an array) directly by position, but it can just as well traverse a linked list or the 
leaves of a balanced tree, or for example iterate over the union of two other iterators. 

Iterators are consumed by iteration. Hence, if the same sequence needs to be it- 
erated twice, a fresh iterator is needed. If iteration is cheap, an iterator can support 
multiple iterations by providing a reset operation. Otherwise, a cache iterator takes an 
arbitrary range iterator as input, iterates it completely, and stores the obtained ranges 
in an array. Its operations then use the array. The cache iterator implements a reset 
operation, so that the possibly costly input iterator is used only once, while the cache 
iterator can be used as often as needed. 

Iterators for variables. The two basic set-valued operations on integer variables are 
domain access and domain update. For an integer variable x, the operation x.getdom() 
returns a range iterator for ranges The operation x.setdom(r) updates the vari- 
able domain of x to set(r) given a range iterator r, provided that set(r) C d{x). The 
responsibility for ensuring that set(r) C d{x) is left to the programmer. 

In order to provide safer and richer operations, we can use iterator combinators. 
For example, an intersection iterator r = iinter(ri,r2) combines two range iterators 
r\ and r2 such that set(r) = set(ri) n set(r2). Similarly, a difference iterator r — 
iminus(ri,r2) yields set(r) = set(ri) \set(r2). 

Richer set- valued operations are then effortless. The operation x.ad jdom(r) ad- 
justs the domain d{x) by set(r), yielding nset(r), whereas x.excdom(r) excludes 
set(r) from d{x), yielding d{x) \ set(r): 

;ic.ad jdom(r) = x.setdom(iinter(x.getdom(),r)) 
x.excdom(r) = x.setdom(iminus(x.getdom(),r)) 

In contrast to the x.setdom(-) operation, the richer set-valued operations are inher- 
ently contracting, and thus safer to use when implementing a propagator. 

Iterators also serve as the natural interface for operations on set variables, which are 
usually approximated as set intervals defined by a lower and an upper bound [25, 13]: 

d{x) = [glb(d(x)) .. \uh{d{x))] = {s I glh{d{x)) C s,s C \uh{d{x))} 
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In order to access and update these set bounds, propagators use set-valued op- 
erations based on iterators: x.glb() returns a range iterator for ranges(glb(ii(x))), 
x.lub() returns a range iterator for ranges(lub(ii(x))), x.ad jglb(r) updates the do- 
main ofxto [glb(ii(x)) U set(r),lub(ii(x))], and x.ad j lub(r) updates the domain ofx 
to [glb(£/(x)),lub(t/(x))nset(r)]. 

Iterator combinators provide the operations that set propagators need: union, in- 
tersection, difference, and complement. Many propagators can thus be implemented 
directly using iterators and do not require any temporary data structures for storing 
set-valued intermediate results. 

All set-valued operations are parametric with respect to the iterator r. any range 
iterator can be used. As for parametric propagators, an implementor has to decide 
on the kind of parametricity to use. Gecode uses template-based parametric polymor- 
phism, with the performance benefits due to monomorphization and consequent code 
optimization mentioned previously. 

Advantages. Range iterators provide essential advantages over an explicit set rep- 
resentation. First, any range iterator regardless of its implementation can be used in 
domain operations. This turns out to result in simple, efficient, and expressive domain 
updates. Second, no costly memory management is required to maintain a range iter- 
ator as it provides access to only one range at a time. Third, the abstractness of range 
iterators makes them compatible with views and derived propagators: the necessary 
view transformations can be encapsulated in an iterator, as discussed below. 

Iterators for views. As iterators hide their implementation, they are perfectly suited 
for implementing the transformations required for set- valued operations on views. 

Set- valued operations for constant integer views are straightforward. For a constant 
view V on constant k, the operation v.getdom() returns an iterator for the singleton 
range sequence {[k ..k]). The operation v.setdom(r) just checks whether the range 
sequence of r is empty (in order to detect failure). 

Set-valued operations for an offset view are provided by an ojfset iterator. For a 
range sequence r — ([m,- .. n(])jLi and offset c, ioffset(r, c) iterates ([m/ + c .. n; + c])^^[. 
An offset view on x with offset c then implements getdom as ioffset(x.getdom(),c) 
and setdom(r) as x.setdom(ioffset(r, — c)). 

For minus views we just give the range sequence, iteration is obvious. For a given 
range sequence ([m,- .. n,])*^j, the negative sequence is obtained by reversal and sign 
change as ([— n^i-i+i .. — 'M*:-i+i])f=i- The same iterator for this sequence can be used 
both for setdom and getdom operations. Note that implementing the iterator is in- 
volved as it changes direction of the range sequence. There are two different options 
for changing direction: either the set-valued operations accept iterators in both direc- 
tions or a cache iterator is used to reverse the direction. Gecode uses the latter and 
Section 7.2 evaluates the overhead introduced by cache iterators. 

A scale iterator provides the necessary transformations for scale views. Assume 
a scale view on a variable x with a coefficient a > 0, and let ([;«, .. be a range 

sequence for d{x). If a = 1, the scale iterator does not change the range sequence. Oth- 
erwise, the corresponding scaled range sequence is ({a x mi}, {a x (mi + 1 )},..., {a x 
n 1 },..., {fl X m^t}, {a x (mj. + 1 )},..., {a x njt}}. For the other direction, assume we 
want to update the domain using a set S through a scale view. Assume that ([m, .. n(]),=i 
is a range sequence for S. Then for 1 < / < A; the ranges [[m,7a] .. correspond 
to the required variable domain for x, however they do not necessarily form a range 
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sequence as the ranges might be empty, overlapping, or adjacent. Iterating the range 
sequence is however simple by skipping empty ranges and merging overlapping or ad- 
jacent ranges. Scale views for a variable x and a coefficient a in Gecode are restricted 
to be strictly positive so as to not change the direction of the scaled range sequence. A 
negative coefficient can be obtained by using a scale view together with a minus view. 

A complement view of a set variable x uses a complement iterator, which given a 
range iterator r iterates over set(r). 

6 Limitations 

Although views are widely applicable, they are no silver bullet. This section explores 
some limitations of the presented model. 

Beyond injective views. Views are required to be injective, as otherwise o (p is 
no longer the identity function, and derived propagators would not necessarily be con- 
tracting. An example for this behavior is a view for the absolute value of an integer 
variable. Assuming a variable domain d{x) — {!}, an absolute value view <p would 
leave the domain as it is, <p{d){x) = {!}, but the inverse would "invent" the negative 
value, {<p{d)){x) = { — 1,1}. With an adapted definition of derived propagators, 
such as (p{p){d) = (p^ {p{(p{d))) Dd, non-injective views could be used - however, 
many of the proofs in this paper rely on injectivity (though some of the theorems pos- 
sibly still hold for non-injective views). 

Multi-variable views. Some multi-variable views that seem interesting for practical 
applications do not preserve contraction, for instance a view on the sum or product of 
two variables. The reason is that removing a value through the view would have to 
result in removing a tuple of values from the domain. As domains can only represent 
Cartesian products, this is not possible in general. Such a view would have two main 
disadvantages. First, if propagation of the original constraint is strong but does not lead 
to an actual domain pruning through the views, then the potentially high computational 
cost for the pruning does not pay off. A cheaper but weaker, dedicated propagation 
algorithm or a different modeling with stronger pruning is then a better choice. Second, 
if views do not preserve contraction, then Proposition 5 does not hold. That means that 
a propagator p cannot easily detect subsumption any longer, as it would have to detect 
it for (p{p) instead of just for itself, p. Systems such as Gecode that disable subsumed 
propagators (as described in [33]) then lose this potential for optimization. 

For contraction-preserving views on multiple variables, all the theorems still hold. 
Two such views we could identify are a set view of Boolean variables [bi,...,b„], 
behaving like {/ 1 bj = 1}; and an integer view of Boolean variables [bi,... ,bn], where 
bi is 1 if and only if the integer has value i; as well as the inverse views of these two. 

Propagator invariants. Propagators typically rely on certain invariants of a variable 
domain implementation. If idempotency or completeness of a propagator depend on 
these invariants, type conversion views lead to problems, as the actual variable imple- 
mentation behind the view may not respect the same invariants. 

For example, a propagator for set variables based on the set interval approximation 
can assume that adjusting the lower bound of a variable does not affect its upper bound. 
If this propagator is instantiated with a type conversion view for an ROBDD-based set 
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Table 2: Results for Gecode 3.1.0, the baseline for the experiments 



UCm^HrHHi IS. 


tim^^ { m K \ 

i Ir/IL- ( //l*> / 


iiidii. 1 ivuytc 1 


f/'llhlFfi' c 
ILiilLtr 


nr/tn/'i ontinrt v 

IJI L/fJLil^Lti lUtt^ 


All-Interval (50) 


183.21 


148 





6685 


All-Interval (100) 


3904.21 


516 





25866 


Alpha (naive) 


100.00 


23 


7435 


136179 


BIBD (7-3-60) 


1762.85 


4516 


1306 


921686 


Eq-20 


1.52 


14 


54 


3460 


Golomb Rulers (Bnd, 10) 


423.39 


67 


8890 


1 181704 


Golomb Rulers (Dom, 10) 


607.86 


419 


8890 


1 181770 


Graph Coloring 


324.46 


3910 


1 too 


125 264 


Magic Sequence (Smart, 500) 


251.50 


4484 


251 


84302 


Magic Sequence (GCC, 500) 


305.15 


330 


251 


3908 


Pailition (32) 


5928.04 


265 


160258 


12 107504 


Perf ect Squai'e 


185.54 


3972 


150 


305391 


Queens (10) 


36.88 


27 


4992 


43448 


Queens (Dom, 10) 


1 m 
IUd.jo 


OQ 


1 Q/ln 

jy4u 




Queens (100) 


1.54 


235 


22 


455 


Queens (Dom, 100) 


31.83 


2056 


8 


693 


Sorting (400) 


1400.01 


151413 





459501 


Social Golfers (8-4-9) 


193.37 


10254 


32 


181290 


Social Golfers (5-3-7) 


1 199.51 


2117 


1 174 


852391 


Hamming Codes (20-3-32) 


1 140.98 


24746 


2296 


753751 


Steiner Triples (9) 


120.11 


901 


1067 


297501 


Sudoku (Set, 1) 


3.48 


83 





1820 


Sudoku (Set, 4) 


7.30 


148 


1 


3752 


Sudoku (Set, 5) 


55.14 


514 


25 


28038 



variable (see Section 4.4), this invariant is violated: if, for instance, the current domain 
is {{1,2}, {3}}, and 1 is added to the lower bound, then 3 is removed from the upper 
bound (in addition to 2 being added to the lower bound). If a propagator reports that it 
has computed a fixed point based on the assumption that the upper bound cannot have 
changed, it may actually not be at a fixed point. This potentially results in incorrect 
propagation, for instance if the propagator could detect failure if it were run again. 

7 Evaluation 

While Section 3 proved that derived propagators are perfect with respect to the mathe- 
matical model, this section shows that in most cases one can also obtain perfect imple- 
mentations of derived propagators, not incurring any performance penalties compared 
to dedicated, handwritten propagators. 

Experimental setup. The experiments are based on Gecode 3.1.0, compiled using 
the GNU C++ compiler gcc 4.3.2, on an Intel Pentium IV at 2.8 GHz running Linux. 
Runtimes are the average of 25 runs, with a coefficient of deviation less than 2.5% for 
all benchmarks. All example programs are available in the Gecode distribution. Table 2 
shows the figures for the unmodified Gecode 3.1.0 (pure integer models above, mod- 
els with integer and set variables below the horizontal line), and results will be given 
relative to these numbers. For example, a runtime of 130% means that the example 
needs 30% more time, while 50% means that it is twice as fast as in Gecode 3.1.0. The 
column time shows the runtime, mem. the peak allocated memory, /a/ZMrei the number 
of failures during search, and propagations the number of propagator invocations. 
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Table 3: Relative performance of decomposition, compared to views 



Ucrll^tlUlLlf IS. 


fiyti/3 ^/n 
time iV 




ni'/in/'io/'itirtin.' 

IJI L/fJLil^Lti ILftt^ iV 


Alpha (naive) 


412.88 


360.87 


673.83 


BIBD (7-3-60) 


308.80 


211.94 


256.12 


Eq-20 


590.35 


700.00 


704.57 


railition i^jl) 




1 i J. JO 


1 JD.4U 


Perfect Square 


114.46 


109.67 


104.42 


Queens (Dom, 10) 


173.32 


100.00 


519.68 


Queens (Dom, 100) 


140.60 


103.11 


2371.86 


Social Golfers (8-4-9) 


335.89 


234.82 


160.22 


Social Golfers (5-3-7) 


217.28 


190.69 


150.58 


Hamming Codes (20-3-32) 


113.81 


104.66 


99.65 


Steiner Triples (9) 


132.79 


100.00 


101.76 


Sudoku (Set, 1) 


166.18 


100.00 


110.38 


Sudoku (Set, 4) 


152.82 


110.81 


107.06 


Sudoku (Set, 5) 


143.63 


100.00 


105.47 



As many of the experimental results rely on the optimization capabilities of the used 
C++ compiler, we verified that all experiments yield similar results with the Microsoft 
Visual Studio 2008 C++ compiler 

7.1 Views Versus Decomposition 

In order to evaluate whether deriving propagators is worth the effort in the first place, 
this set of experiments compares derived propagators with their decompositions, re- 
vealing a significant overhead of the latter. 

Table 3 shows the results of these experiments. For Alpha and Eq-20, linear equa- 
tions with coefficients are decomposed. For Queens 100, we replace the special all- 
different-with-offsets by its decomposition into an all-different propagator and binary 
equality-with-offset propagators. In BIBD and Perfect Square, we decompose ternary 
Boolean propagators, implementing x A y ^ z as -ix V ^ -iz in BIBD, and xVy ^ z 
as -ijc A -ly ^ -^z in Perfect Square. In the remaining examples, we decompose a set 
intersection into complement and union propagators. 

Some integer examples show a significant overhead of around six times the run- 
time and memory when decomposed. The overhead of most set examples as well as 
Perfect Square is moderate, partly because no additional variable was introduced if the 
model already contained its complement or negation. As to be expected, decomposi- 
tion often needs significantly more propagation steps, but as the additional steps are 
performed by cheap propagators (like x = y + i or x = -^y), the runtime effect is less 
drastic. Queens 100 is an extreme case, where 23 times the propagation steps only 
cause 40% more runtime. The reason is that the scheduling order does not take advan- 
tage of the fact that the decompositions are Berge-acyclic as discussed in Section 3.5. 
Partition 32 has a single linear equation with coefficients, several linear equations with 
unit coefficients, multiplications, and a single all- different. Replacing the linear equa- 
tion by its decomposition has little effect on the runtime (35% overhead). 

7.2 Impact of Derivation Techniques 

The techniques presented in Section 4 have different impacts on the performance of the 
derived propagators. 
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Table 4: Relative performance of minus views 



Benchmark 


time % 


prop. % 


Benchmark 


time % 


prop. % 


All-Interval (50) 


100.00 


100.00 


Partition (32) 


131.83 


135.95 


All-Interval (100) 


100.52 


100.00 


Queens (10) 


98.32 


100.00 


Alpha (naive) 


101.81 


100.00 


Queens (Dom, 10) 


107.63 


100.00 


Golomb Rulers (Bnd, 10) 


99.36 


100.01 


Queens (100) 


97.83 


100.00 


Golomb Rulers (Dom, 10) 


107.77 


100.18 


Queens (Dom, 100) 


95.62 


100.00 


Graph Coloring 


107.19 


99.84 


Sorting (400) 


105.13 


100.00 



Generalization and specialization. These techniques can be implemented without 
any performance overhead compared to a handwritten propagator This is not sur- 
prising as the only potential overhead could be that a function call is not resolved at 
compile time. For example, a thorough inspection of the code generated by the GNU 
C++ compiler and the Microsoft Visual Studio C++ compiler shows that they are able to 
fully inline the operations of offset and scale views. 

Transformation and type conversion. These techniques can incur an overhead com- 
pared to a dedicated implementation, as the transformations performed by the views 
can sometimes not be removed by compiler optimizations, and type conversions may 
be costly if the data structures for the variable domains differ significantly. 

For example, a propagator instantiated with two minus views of variables x and y 
may include a comparison, (— x) < (— y). Due to the invariants guaranteed by views, 
this is equivalent to y < x, saving two negations. However, the asymmetry in the two's 
complement representation of integers prevents the compiler from performing this op- 
timization. As an experiment to evaluate this effect, we instantiated an all-different 
propagator with minus views. The resulting derived propagator of course implements 
the same constraint, but incurs the overhead of negation. Similarly, we replaced the 
max propagator in the Sort example with a min (where the propagator for min is de- 
rived from the propagator for max) and negated all parameters. According to the results 
in Table 4, the overhead is often negligible, and only exceeds 5% in examples that use 
the domain-complete all-different propagator (Graph Coloring, Golomb Rulers Dom 
and Queens Dom) or predominantly min propagators (Sort). Queens Dom 100 does 
not show the effect as the runtime is dominated by search. Using minus views can 
result in different propagator scheduling. The Partition example shows this behavior, 
where the increase in propagation steps results in increased runtime. 

It is interesting to note that the domain-complete all-different propagator, when 
instantiated with minus views, requires a cache iterator for sequence reversal (as dis- 
cussed in Section 5.4). Surprisingly, the overhead of minus views is largely indepen- 
dent of the use of cache iterators which is confirmed in Section 7.4. 

Other transformations are translated optimally, such as turning {—x) — {—y) into 
y —X. Boolean negation views also lead to optimal code, as they do not compute I —x 
for a Boolean variable x, but instead swap the positive and negative operations. 

Set-valued transformations can result in non-optimal code. For example, a propa- 
gator for ternary intersection, x — yDz, will include an inference .it.ad j glb(y.glb() n 
z.glb()). To derive a propagator for x = y Uz, we instantiate the intersection propaga- 
tor with complement views for x, y, and z, yielding the following inference: 

I.ad jglb(y.glb() ni.glbO) 
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Table 5: Relative performance of views compared to dedicated set propagators 



Benchmark 


time % 


Benchmark 


time % 


Social Golfers (8-4-9) 
Social Golfers (5-3-7) 
Hamming Codes (20-3-32) 
Steiner Triples (9) 


166.31 
148.83 
129.11 
127.85 


Sudoku (Set, 1) 
Sudoku (Set, 4) 
Sudoku (Set, 5) 


167.44 
151.74 
142.83 





Table 6: Relative performance of virtual method calls 



Benchmark 


time % 


Benchmark 


time % 


All-Interval (50) 


182.63 


Social Golfers (8-4-9) 


148.37 


All-Interval (100) 


113.20 


Social Golfers (5-3-7) 


138.95 


Alpha (naive) 


153.59 


Hamming Codes (20-3-32) 


131.37 


BIBD (7-3-60) 


138.50 


Steiner Triples (9) 


149.08 


Eq-20 


211.69 


Sudoku (Set, 1) 


119.56 


Golomb Rulers (Bnd, 10) 


220.01 


Sudoku (Set, 4) 


118.78 


Golomb Rulers (Dom, 10) 


170.13 


Sudoku (Set, 5) 


119.17 


Graph Coloring 


104.29 






Magic Sequence (Smart, 500) 


136.58 






Magic Sequence (GCC, 500) 


226.64 






Partition (32) 


187.89 






Perfect Square 


130.64 






Queens (10) 


133.81 






Queens (100) 


160.79 







which amounts to computing 



Jt:.adjlub(3'.lub()nz.lub()) 

It would be more efficient to implement the equivalent jc. ad j lub(3'.lub() Uz.lub()) 
because this requires three set operations less. Unfortunately, no compiler will find 
this equivalence automatically, as it requires knowledge about the semantics of the set 
operations. Table 5 compares a dedicated propagator for the constraint xHy — z with a 
version using complement views and a propagator for xUy — z- The overhead of 27% 
to 67% does not render views useless for set variables, but it is nevertheless significant. 

7.3 Templates Versus Virtual Methods 

As suggested in Section 5, in C++, compile-time polymorphism using templates is far 
more efficient than virtual method calls. To evaluate this, we changed the basic oper- 
ations of integer variables to be virtual methods, such that view operations need one 
virtual method call. In addition, all operations that use templates (and can therefore not 
be made virtual in C++) have been changed so that they cannot be inlined, to simulate 
virtual method calls. This is a conservative approximation of the actual cost of fully 
virtual views. The results of these experiments appear in Table 6. Virtual method calls 
cause a runtime overhead between 4% and 127% for the integer examples (left table), 
and 18% to 49% for the set examples (right table). The runtime overhead for set exam- 
ples is lower as the basic operations on set variables are considerably more expensive 
than the basic operations on integer variables. 
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Table 7: Relative performance of cache iterators 



Benchmark 


time % 


Benchmark 


time % 


All-Interval (50) 


102.48 


Social Golfers (8-4-9) 


522.62 


All-Interval (100) 


101.17 


Social Golfers (5-3-7) 


450.15 


Golomb Rulers (Bnd, 10) 


100.51 


Hamming Codes (20-3-32) 


297.38 


Golomb Rulers (Dom, 10) 


128.98 


Steiner Triples (9) 


304.97 


Graph Coloring 


144.58 


Sudoku (Set, 1) 


459.85 


Magic Sequence (GCC, 500) 


103.56 


Sudoku (Set, 4) 


483.27 


Queens (Dom, 10) 


187.36 


Sudoku (Set, 5) 


436.92 


Queens (Dom, 100) 


155.62 





7.4 Iterators Versus Temporary Data Structures 

The following experiments show that using range iterators improves the efficiency of 
propagators, compared to the use of explicit set data structures for temporary results. 

For the experiments, temporary data structures have been emulated by wrapping all 
iterators in a cache iterator as described in Section 5.4. Table 7 shows the results. For 
integer propagators that perform the safe iterator-based domain operations introduced 
in Section 5.4, computing with temporary data structures results in 28% to 87% over- 
head {Golomb Rulers Dom, Graph Coloring, Queens Dom). For set propagators, which 
make much more use of iterators than integer propagators, the overhead becomes pro- 
hibitive, resulting in up to 4.8 times the runtime. The memory consumption does not 
increase, because iterators are not stored, and only few iterators are active at a time. 

8 Conclusion 

The paper has developed views for deriving propagator variants. Such variants are 
ubiquitous, and the paper has shown how to systematically derive propagators using 
different types of views, corresponding to techniques such as transformation, general- 
ization, specialization, and type conversion. 

Based on a formal, implementation independent model of propagators and views, 
the paper has identified fundamental properties of views that result in perfect derived 
propagators. The paper has shown that a derived propagator inherits correctness and 
domain completeness from its original propagator, and bounds completeness given ad- 
ditional properties of the used views. 

The paper has presented an implementation architecture for views based on para- 
metricity. The propagator implementation is kept parametric over the type of view that 
is used, so that deriving a propagator amounts to instantiating a parametric propaga- 
tor with the proper views. This implementation architecture is an orthogonal layer of 
abstraction that can be implemented on top of any constraint solver. 

An empirical evaluation has shown that views have proven invaluable for the im- 
plementation of Gecode, saving huge amounts of code to be written and maintained. 
Furthermore, deriving propagators using templates in C++ has been shown to yield com- 
petitive (in most cases optimal) performance compared to dedicated handwritten prop- 
agators. The experiments have also clarified that deriving propagators is vastly superior 
to decomposing the constraints into additional variables and simple propagators. 
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